In typical database systems, users store, update and retrieve information by submitting commands to a database application. To be correctly processed, the commands must comply with the database language that is supported by the database application. One popular database language is known as Structured Query Language (SQL).
A logical unit of work that is comprised of one or more database language statements is referred to as a transaction. In a database server, a memory area called the System Global Area (SGA) is allocated and one or more processes are started to execute one or more transactions. The combination of the SGA and the processes executing transactions is called a database server.
Some database systems provide a buffer cache that is shared among the processes that are executing transactions in a database. The buffer cache resides in a portion of the SGA and holds database information. Buffers in the buffer cache hold copies of data blocks that have been read from the data files of the database. User processes concurrently connected to a database server instance share the buffers. When a transaction desires to make a change to a data block, a copy of the data block is loaded into a buffer of the buffer cache and the change is made to the copy of the data block stored in the database buffer cache in dynamic memory. At some time subsequent to when a transaction makes a change data in the buffer cache, one of the database processes, referred to herein as the “database writer,” writes the modified blocks of data from the database buffer cache to the data files on disk.
A major aspect of database operation and administration involves the recovery of the database from the various types of failures encountered. One approach to safeguard a database against possible failures involves maintaining logs of operations. According to the logging approach, several different operation logs are maintained to perform various database maintenance functions. Specifically, a redo log is used to store database operations so that the operations can be re-performed to restore the database to its pre-failure state after a failure. For example, when a transaction modifies data in the data cache, a redo entry that specifies the modification is stored in a redo log on disk. If a failure occurs before the updated data within the buffer cache has been stored to disk, the modified data in the buffer cache may be lost. Under these conditions, the database may be modified based on the redo entry during the recovery process.
The basic component of a log system is a log file stored on disk. Redo log files are filled with redo entries that store low-level representations of database changes. Redo entries contain the information necessary to reconstruct, or redo, changes made by data operations such as INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP. Redo entries are generated for each change made to a copy of a data block stored in the database buffer cache. In one implementation, a redo log buffer is a circular buffer that holds information about update operations recently performed by transactions. The redo log buffer is written to an online redo log file group on disk by a background process. The records in the online redo log file group on disk are referred to as redo logs.
According to one approach, multiple redo log files exist simultaneously, but only one of them is current. Each online redo log file is associated with a specified maximum size. As redo blocks are written to the current online redo log file, the current size of the current online redo log file increases. When the current size reaches the maximum size, the current online redo log file is archived. When the current online redo log file is archived, a copy of the current online redo log file is stored to a designated location, and another online redo log file becomes the current online redo log file.
After an online redo log-file has been archived, new redo blocks are not written to the archived copy of the redo log file. However, at a later time, the online redo log file (not the archived copy) may, once again, become the current online redo log file, and may be reused then. When the online redo log once again becomes the current online redo log file, old redo logs entries in the online redo log file may be overwritten by new redo blocks.
Replication is one technique used to maintain the availability of database systems. Replication is the process of replicating data from a “primary” database onto another database, herein referred to as a “standby” database. According to one approach, when a redo log file is archived, a copy of the archived redo log file is sent to a recovery process that executes in association with the standby database, herein referred to as the standby recovery process. The standby recovery process receives the archived redo log file and replicates, on the standby database, the changes indicated in the archived redo log file. If the primary database becomes unavailable, the standby database can be made primary.
One approach to replication is the “physical standby” approach. Under this approach, the changes made to data blocks on the primary database are made to replicas of those data blocks on a physical standby database. Because the primary database system is replicated at the lowest atomic level of storage space on the standby database, the physical standby database is a physical replica of the primary database.
Another approach to replicating data is the “logical standby” approach. Under the logical standby approach, database commands that modify data on the primary database are re-executed on a logical standby database. While executing the same database commands guarantees that changes are replicated at the record level, the changes are not replicated at the data block level. This change in replication strategy allows a logical standby database to be available to reporting applications while replication is being performed.
As discussed above, according to one approach, a standby recovery process replicates, on the standby database, changes indicated in an archived redo log file. Consequently, the standby recovery process does not replicate, on the standby database, changes made in the primary database until the redo log file that contains the changes is archived. As discussed above, a current online redo log file typically is not archived, and the resulting archived redo log file typically is not sent to the standby recovery process, until the current online redo log file's maximum size has been reached.
Consequently, at some moments in time, the data contained in a standby database might not be an accurate replica of the data contained in a primary database. If a query to the standby database was allowed at such times, then the results returned by the query might differ from results that would have been returned if the primary database were queried. Additionally, in the event that the primary database failed, then, before the standby database could be made primary, the standby recovery process might need to “catch up” with the changes not yet made to the standby database—changes indicated by redo entries in the not-yet-archived current online redo log file. This could cause a delay between the time that a primary database failed and the time that a standby database was made primary. Consequently, this could equate to a significant gap in data availability.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.